1. Field of the Invention
This invention relates to computer systems and, more particularly, to backup and restoration of data within computer systems.
2. Description of the Related Art
Many business organizations and governmental entities rely upon applications that access large amounts of data, often exceeding many terabytes of data, for mission-critical applications. Numerous different types of storage devices, potentially from multiple storage vendors, with varying functionality, performance and availability characteristics, may be employed in such environments.
Any one of a variety of factors, such as system crashes, hardware storage device failures, software defects, or user errors (e.g., an inadvertent deletion of a file) may potentially lead to data corruption or to a loss of critical data in such environments. In order to recover from such failures, various kinds of backup techniques may be employed. Traditionally, for example, backup images of critical data may have been created periodically (e.g., once a day) and stored on tape devices. However, a single backup version of production data may not be sufficient to meet the availability requirements of modern mission-critical applications. For example, for disaster recovery, it may be advisable to back up the data of a production application at a remote site, but in order to be able to quickly restore the data in the event of a system crash or other error unrelated to a large-scale disaster, it may be advisable to store a backup version near the production system. As a consequence, in some storage environments, multiple stages of backup devices or hosts may be employed. A first backup version of a collection of production files may be maintained at a file system at a secondary host, for example, and additional backup versions may be created periodically at tertiary hosts from the secondary host file system. The use of multiple stages may also help to reduce the impact of backup operations on production application performance. In some environments, multiple layers of additional backup versions may be generated for additional enhancements to availability: for example, production data may be copied from a production host or server to a first layer backup host, from the first layer to a second layer, from the second layer to a third layer, and so on.
In some storage environments where multiple stages of backup are implemented, the backup operations at different stages may be performed according to independent schedules. For example, a replicator (which may also be termed a replication engine) may be configured to periodically synchronize a replica of a primary data object set according to a first schedule, and a snapshot generator may be configured to create snapshots or point-in-time copies from the replica according to a second schedule. The snapshot generator may not be aware of the replication state of various data objects of which a snapshot is to be taken—that is, some data objects may only partially replicated or partially synchronized at the time that a snapshot is scheduled. If a snapshot includes a point-in-time copy of an inconsistent data object (e.g., a replica that is not fully consistent with its corresponding primary object), and the snapshot is used as a source for data restoration, data corruption may occur if the copy of the inconsistent data object is restored. Requiring that all replicated data objects must be in a consistent state at the time a snapshot is generated may be impractical, especially in environments where multiple streams of replication and/or snapshot generation are supported and are independently scheduled with respect to each other. For example, if replicas of several 100 GB file are being synchronized, waiting for the replication of the files to complete before generating a snapshot may result in a disruption of a desired snapshot schedule.